查看原文
其他

面对Schema free的MongoDB,如何规范你的schema

2016-01-15 周李洋 DBAplus社群



作为近年最为火热的文档型数据库,MongoDB受到了越来越多人的关注,但是由于国内的MongoDB相关技术分享屈指可数,不少朋友都在抱怨无从下手。本期【DBA+社群】联合发起人周李洋为大家分享面对Schema free 的MongoDB时,如何规范你的schema。将从实际应用的角度,并覆盖调优,troubleshooting等方面来进行MongoDB的干货分享,希望能对大家带来帮助。


目录:

  • MongoDB文档模型带来的好处

  • Variety

  • 我们为什么要用Variety呢?

  • Document Validation

  • validation的限制


如果希望了解更多MongoDB基础的信息,还请大家Google下。我们知道MongoDB是一个文档型数据库,scheme free 是其非常重要的特性,但是在生产中我们应该怎么如合理利用这个特性,合理处理MongoDB的schema呢?


一、MongoDB文档模型带来的好处


大家都知道MongoDB是文档型数据库,是Schema Free的。那么MongoDB的文档模型能给我们带来哪些好处呢,在这简单列举几个:


1、json形式


在MongoDB中,开发人员可以直接将一个json数据存储进MongoDB,这对于开发人员来说是非常友好额;


2、读写性能高


在关系型数据库中,我们经常会进行join、子查询等关联性需求,这时候往往会带来较多的随机IO,而在MongoDB中,我们可以通过合理的数据模型设计来将很多的关联需求通过内嵌、反范式的方式实现,减少了随机IO;


3、schema free


MongoDB的数据模型是灵活的,无需为了Online DDL而操心,不同的document也可以有不同的结构。


在这,我们不深入探究如何对于MongoDB 的Schema进行设计、建模,有关这部分内容,推荐大家可以阅读TJ在开源中国的年终盛典会上分享《MongoDB 进阶模式设计》,以及《Retail Reference Architecture Part 1 to 4 》。


在此我们将主要针对进行了初步建模、并正式上线服务后的schema进行巡检与检测的方式来进行讨论。


二、Variety


Variety是一个开源的,非常使用的,检测mongodb表字段类型、分布的一个开源工具。正如其github readme中第一句所说"**Meet Variety, a Schema Analyzer for MongoDB**"。


Variety能够帮助我们检测我们MongoDB表中的字段类型、分布,并生产报表,可以让我们非常直观的对现有表结构、字段类型进行分析,并找出数据模型中的隐患。


下面我们通过例子来进行讲解:


首先,建立一个表




我们来看看通过variety获得的结果




test是我们的db名,users是表名。我们可以看到,针对我们之前插入的5条数据,variety跑出的结果是:


所有的document都含有_id,和name字段,60%的document含有bio字段,40%的document含有birthday和pets字段,且pets字段有2个类型的数据(4个array的,1个string的),20%的document含有someBinData和SomeWeirdLegacyKey字段。


然而生产环境中由于我们的数据量较大,比如一个表有10亿条数据,全部进行扫描会耗时较长,可能我们仅希望对1000条数据进行分析,这时候就可以使用limit来限定。




由于MongoDB的可以通过内嵌来减少联合查询的需求,可以通过反范式来减少随机IO,所以很可能会有嵌套出现在我们的document中。有的时候嵌套的层数太多了,影响我们的统计信息,怎么办,我们可以通过maxDepth来限制。请参考下面的例子:




又或者我们希望指定统计的条件,比如希望caredAbout为true的,可以这样做:


```

$ mongo test --eval "var collection = 'users', query = {'caredAbout':true}" variety.js

```


又或者是希望进行排序:


```

$ mongo test --eval "var collection = 'users', sort = { updated_at : -1 }" variety.js

```


同时我们也可以指定分析结果的format:


```

$ mongo test --quiet --eval "var collection = 'users', outputFormat='json'" variety.js

```

一般在生产中, 我们不会在primary上进行分析, 我们可以在一个priority为0,且为hidden的secondary上进行分析,这时候需要指定slaveOK:


```

$ mongo secondary.replicaset.member:31337/somedb --eval "var collection = 'users', slaveOk = true" variety.js

```

又或者说我们希望将分析结果存在mongo中:


```

$ mongo test --quiet --eval "var collection = 'users', persistResults=true" variety.js

```


并且指定存储的详细信息:


- resultsDatabase 分析结果所存储的db名

- resultsCollection 分析结果所存储的collection名

- resultsUser 分析结果存储的实例的user

- resultsPass 分析结果所存储的实例的password


```

mongo test --quiet --eval "var collection = 'users', persistResults=true, resultsDatabase='db.example.com/variety' variety.js

```


三、我们为什么要用Variety呢?


尽管我们MongoDB是Schema Free的,但是绝大多数情况下, 我们都希望字段类型统一。


不一致的字段类型可能会为我们的数据带来误差,试想一下,如果某个字段的字段类型不统一,而我们却不知情,这时候很可能会发现业务查询有数据丢失,数据不准确。


并且在生产环境中,应用的版本在不断迭代,需求不断增多,字段也随之变化,如果在没有规范化的上线流程检查过后,数据库中可能还会存在部分数据的字段确实,比如有的document有a字段,有的却没有,variety也可以帮助我们发现这些问题。


四、Document Validation


MongoDB 3.2推出了很多给力的功能,在这不得不提及Document Validation,Document Validation的出现我想也是MongoDB官方想表达”schema free but you may need some rules”吧,哈哈,纯属臆测。


简单介绍下Document Validation:


我们可以为我们schema free的mongodb collection做一些限制。当然这并不是意味着MongoDB变成了关系型数据库,个人觉得这反而更好的突出了MongoDB Schema free的特性。在正确的地方、需要的地方schema free,在适当的地方要有限制。


假设我们要新建一个表contacts,要有如下约束:


phone字段为string类型或者email字段要匹配”@mongodb.com”结尾,或者status为”Unknown”或者"Incomplete"




对已经建立了的表,我们可以通过如下方式来做限定:




这里可以看到,多了一个validationLevel参数,我们可以在设置validation的时候指定我们的validationLevel级别:


- 默认级别是strict,对该collection已有的和以后新增的document都进行validation验证;



- 可以设置为moderate,仅对已经存在的document进行validation限定;


同时还有validationAction参数来指定当有不符合validation规则的数据进行update或者insert的时候, 我们mongodb实例如何进行处理。


- 默认级别为error,mongodb将拒绝这些不符合validation规则的insert和update。

- 可以设置为warn,mongodb会在日志中记录,但是允许这类insert和update操作。日志中如:



五、validation的限制


- validation不能对admin、local和config库中的collection进行设置;

- 不能对system.*这类collections进行validation设置;


作者介绍:周李洋

  • 【DBA+社群】联合发起人

  • 社区常用ID eshujiushiwo,Teambition运维总监

  • MongoDB Contribution Award获得者,大陆首位MongoDB Certified Professional

  • MongoDB上海用户组发起人

  • CSDN MongoDB版主。关注Mysql与MongoDB技术,数据架构,服务器架构,高效运维等。

  • mongo-mopre,mongo-mload作者

  • MongoDB官方翻译组核心成员,MongoDB中文站博主



小编精心为大家挑选了近日最受欢迎的几篇热文:

回复001,看杨志洪《【职场心路】一个老DBA的自白》;

回复002,看丁俊的《【重磅干货】看了此文,Oracle SQL优化文章不必再看!》;

回复003,看胡怡文《PG,一道横跨oltp到olap的梦想之桥》;

回复004,看陈科《memcached&redis等分布式缓存的实现原理》;

回复005,看邹德裕《数据库运维工具化:一切从“简”,只为DBA更轻松》

回复006,看郑晓辉《存储和数据库不得不说的故事》;

回复007,看袁伟翔《揭秘Oracle数据库truncate原理》;

回复008,看杨建荣《立等可取:工具定制让Oracle优化变得更简单快捷》;

回复009,看丁启良《LINUX类主机JAVA应用程序占用CPU、内存过高分析手段》;

回复010,看徐桂林《以应用为中心的企业混合云管理》。

关于DBA+社群

DBA+社群是中国最大的涵盖各种架构师、数据库、中间件的微信社群!线上分享2次/周、线下沙龙1次/月,顶级峰会6次/年,直接受众10000+,间接影响50万+ITer。DBA+社群致力于搭建一个学习交流、专业人脉、跨界合作的公益平台,更多精彩请持续关注dbaplus微信订阅号!


扫码关注

DBAplus社群

超越DBA圈子,连接的不仅仅是DBA

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存